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Abstract 


This memo defines a portion of the Management Information Base (MIB) 
for use with network management protocols in TCP/IP-based internets. 
In particular, it defines objects for managing MAC bridges based on 
the IEEE 802.1D-1998 standard between Local Area Network (LAN) 
segments. Provisions are made for the support of transparent 
bridging. Provisions are also made so that these objects apply to 
bridges connected by subnetworks other than LAN segments. 


The MIB module presented in this memo is a translation of the 
BRIDGE-MIB defined in RFC 1493 to the SMIv2 syntax. 


This memo obsoletes RFC 1493. 
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1. The Internet-Standard Management Framework 


For a detailed overview of the documents that describe the current 
Internet-Standard Management Framework, please refer to section 7 of 
RFC 3410 [RFC3410]. 


Managed objects are accessed via a virtual information store, termed 
the Management Information Base or MIB. MIB objects are generally 
accessed through the Simple Network Management Protocol (SNMP). 
Objects in the MIB are defined using the mechanisms defined in the 
Structure of Management Information (SMI). This memo specifies a MIB 
module that is compliant to the SMIv2, which is described in STD 58, 
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 
[RFC2580]. 


2. Conventions 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", “NOT RECOMMENDED", "MAY", and 


"OPTIONAL", when they appear in this document, are to be interpreted 
as described in BCP 14, RFC 2119 [RFC2119]. 


Norseth & Bell, Eds. Standards Track [Page 2] 


RFC 4188 Bridge MIB September 2005 
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Bis 


Overview 


A common device present in many networks is the Bridge. This device 
is used to connect Local Area Network segments below the network 
layer. 


There are two major modes defined for this bridging: transparent and 
source route. The transparent method of bridging is defined in the 
IEEE 802.1D specification [IEEE8021D]. This memo defines those 
objects needed for the management of a bridging entity that operates 
in the transparent mode, as well as some objects that apply to all 
types of bridges. 


To be consistent with IAB directives and good engineering practices, 
an explicit attempt was made to keep this MIB module as simple as 
possible. This was accomplished by applying the following criteria 
to objects proposed for inclusion: 


1. Start with a small set of essential objects and add only as 
further objects are needed. 


2. Require that objects be essential for either fault or 
configuration management. 


3. Consider evidence of current use and/or utility. 
4. Limit the total number of objects. 


5. Exclude objects that are simply derivable from others in this or 
other MIB modules. 


6. Avoid causing critical sections to be heavily instrumented. The 
guideline that was followed is one counter per critical section 
per layer. 


1 Structure of the MIB Module 


Objects in this MIB module are arranged into subtrees. Each subtree 
is organized as a set of related objects. The overall structure and 
assignment of objects to their subtrees is shown below. Where 
appropriate, the corresponding IEEE 802.1D [IEEE8021D] management 
object name is also included. 
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IEEE 802.1D Name 
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dotidBridge 
dotidBase 
BridgeAddress Bridge.BridgeAddress 
NumPorts Bridge.NumberOfPorts 
Type 
PortTable 
Port BridgePort .PortNumber 
IfIndex 
Circuit 
DelayExceededDiscards .DiscardTransitDelay 
MtuExceededDiscards -DiscardOnError 
dotldstp 
ProtocolSpecification 
Priority SpanningTreeProtocol 
-BridgePriority 
TimeSinceTopologyChange .TimeSinceTopologyChange 
TopChanges - TopologyChangeCount 
DesignatedRoot .-DesignatedRoot 
RootCost -RootCost 
RootPort -RootPort 
MaxAge .MaxAge 
HelloTime -HelloTime 
HoldTime -HoldTime 
ForwardDelay -ForwardDelay 
BridgeMaxAge .BridgeMaxAge 
BridgeHelloTime -BridgeHelloTime 
BridgeForwardDelay .BridgeForwardDelay 
PortTable 
Port SpanningTreeProtocolPort 
-PortNumber 
Priority -PortPriority 
State . SpanningTreeState 
Enable 
PathCost -PortPathCost 
DesignatedRoot .DesignatedRoot 
DesignatedCost -DesignatedCost 
DesignatedBridge .DesignatedBridge 
DesignatedPort -DesignatedPort 
ForwardTransitions 
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dotidTp 
LearnedEntryDiscards 


AgingTime 
FdbTable 
Address 
Port 
Status 
PortTable 
Port 
MaxInfo 
InFrames 
OutFrames 
InDiscards 
dotidStatic 
StaticTable 
Address 
ReceivePort 
AllowedToGoTo 
Status 


The following IEEE 802.1D management objects have not been included 


Bridge MIB 


BridgeFilter.DatabaseSize 
-NumDynamic,NumStatic 
BridgeFilter.AgingTime 


BridgePort.FramesReceived 
.ForwardOutbound 
.-DiscardInbound 


in the BRIDGE-MIB module for the indicated reasons. 


TEEE 802.1D Object 


Bridge.BridgeName 
Bridge.BridgeUpTime 
Bridge.PortAddresses 
BridgePort.PortName 
BridgePort.PortType 
BridgePort .RoutingType 


SpanningTreeProtocol 
.-BridgeIdentifier 


. TopologyChange 
SpanningTreeProtocolPort 

. Uptime 

-PortIdentifier 


- TopologyChangeAcknowledged 


-DiscardLackOfBuffers 


Eds. 


Standards Track 


Disposition 

Same as sysDescr (SNMPv2-MIB) 
Same as sysUpTime (SNMPv2-MIB) 
Same as ifPhysAddress (IF-MIB) 
Same as ifDescr (IF-MIB) 

Same as ifType (IF-MIB) 


Derivable from the implemented 
subtrees 


Combination of dotldStpPriority 
and dotldBaseBridgeAddress 


Since this is transitory, it 
is not considered useful. 
Same as ifLastChange (IF-MIB) 


Combination of dotlidStpPort 
and dotlidStpPortPriority 
Since this is transitory, 
is not considered useful. 
Redundant 


it 
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Transmission Priority These objects are not required 
as per the Pics Proforma and 
are not considered useful. 

.TransmissionPriorityName 
-OutboundUserPriority 
-OutboundAccessPriority 


3.1.1 The dotlidBase Subtree 


This subtree contains the objects that are applicable to all types of 
bridges. 


3.1.2 The dotldStp Subtree 
This subtree contains the objects that denote the bridge’s state with 
respect to the Spanning Tree Protocol. If a node does not implement 
the Spanning Tree Protocol, this subtree will not be implemented. 
3.1.3 The dotlidSr Subtree 
This subtree contains the objects that describe the entity’s state 
with respect to source route bridging. This subtree described in RFC 


1525 [RFC1525] is applicable only to source route bridging. 


3.1.4 The dotldTp Subtree 


This subtree contains objects that describe the entity’s state with 
respect to transparent bridging. If transparent bridging is not 
supported, this subtree will not be implemented. This subtree is 
applicable to transparent-only and SRT bridges. 


3.1.5 The dotldStatic Subtree 


This subtree contains objects that describe the entity’s state with 
respect to destination-address filtering. If destination-address 
filtering is not supported, this subtree will not be implemented. 
This subtree is applicable to any type of bridge that performs 
destination-address filtering. 


3.2 Relationship to Other MIB Modules 
As described above, some IEEE 802.1D management objects have not been 
included in this MIB module because they overlap with objects in 


other MIB modules that are applicable to a bridge implementing this 
MIB module. 
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3.2.1 Relationship to the SNMPv2-MIB 


The SNMPv2-MIB [RFC3418] defines objects that are generally 
applicable to managed devices. These objects apply to the device as 
a whole, irrespective of whether the device’s sole functionality is 
bridging, or whether bridging is only a subset of the device’s 
functionality. 


As explained in Section 3.1, full support for the 802.1D management 
objects requires that the SNMPv2-MIB objects sysDescr and sysUpTime 
be implemented. Note that compliance with the current SNMPv2-MIB 
module requires additional objects and notifications to be 
implemented, as specified in RFC 3418 [RFC3418]. 


3.2.2 Relationship to the IF-MIB 


The IF-MIB [RFC2863] defines managed objects for managing network 
interfaces. A network interface is thought of as being attached to a 


‘subnetwork’. Note that this term is not to be confused with 
‘subnet’, which refers to an addressing partitioning scheme used in 
the Internet suite of protocols. The term ’segment’ is used in this 


memo to refer to such a subnetwork, whether it be an Ethernet 
segment, a ’ring’, a WAN link, or even an X.25 virtual circuit. 


As explained in Section 3.1, full support for the 802.1D management 
objects requires that the IF-MIB objects ifIndex, ifType, ifDescr, 
ifPhysAddress, and ifLastChange are implemented. Note that 
compliance to the current IF-MIB module requires additional objects 
and notifications to be implemented as specified in RFC 2863 
[RFC2863]. 


Implicit in this BRIDGE-MIB is the notion of ports on a bridge. Each 
of these ports is associated with one interface of the ’interfaces’ 
subtree, and in most situations, each port is associated with a 
different interface. However, there are situations in which multiple 
ports are associated with the same interface. An example of such a 
situation would be several ports, each corresponding, one-to-one, 
with several X.25 virtual circuits that are all on the same 
interface. 


Each port is uniquely identified by a port number. A port number has 
no mandatory relationship to an interface number, but in the simple 
case, a port number will have the same value as the corresponding 
interface’s interface number. Port numbers are in the range 
(1..dotldBaseNumPorts). 
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Some entities perform other functionalities as well as bridging 
through the sending and receiving of data on their interfaces. In 
such situations, only a subset of the data sent/received on an 
interface is within the domain of the entity’s bridging 
functionality. This subset is considered to be delineated according 
to a set of protocols, with some protocols being bridged, and other 
protocols not being bridged. For example, in an entity that 
exclusively performs bridging, all protocols would be considered as 
bridged, whereas in an entity that performs IP routing on IP 
datagrams and only bridges other protocols, only the non-IP data 
would be considered as having been bridged. 


Thus, this BRIDGE-MIB (and in particular, its counters) are 
applicable only to that subset of the data on an entity’s interfaces 
that is sent/received for a protocol being bridged. All such data is 
sent/received via the ports of the bridge. 


4. Definitions 


BRIDGE-MIB DEFINITIONS ::= BEGIN 


IMPORTS 

MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 

Counter32, Integer32, TimeTicks, mib-2 
FROM SNMPv2-SMI 

TEXTUAL-CONVENTION, MacAddress 
FROM SNMPv2-TC 

MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 
FROM SNMPv2-CONF 

InterfaceIndex FROM IF-MIB 


rd 


dotidBridge MODULE-IDENTITY 
LAST-UPDATED "2005091900002" 
ORGANIZATION "IETF Bridge MIB Working Group" 
CONTACT-INFO 
"Email: bridge-mib@ietf.org 


K.C. Norseth (Editor) 
L-3 Communications 
Tel: +1 801-594-2809 
Email: kenyon.c.norseth@L-3com.com 
Postal: 640 N. 2200 West. 
Salt Lake City, Utah 84116-0850 
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Les Bell (Editor) 

3Com Europe Limited 
Phone: +44 1442 438025 
Email: elbell@ntlworld.com 
Postal: 3Com Centre, Boundary Way 

Hemel Hempstead 

Herts. HP2 7YU 

UK 


Send comments to <bridge-mib@ietf.org>" 

DESCRIPTION 
"The Bridge MIB module for managing devices that support 
IEEE 802.1D. 


Copyright (C) The Internet Society (2005). This version of 
this MIB module is part of RFC 4188; see the RFC itself for 
full legal notices." 
REVISION "2005091900002" 
DESCRIPTION 
"Third revision, published as part of RFC 4188. 


The MIB module has been converted to SMIv2 format. 
Conformance statements have been added and some 
description and reference clauses have been updated. 


The object dotldStpPortPathCost32 was added to 
support IEEE 802.1t and the permissible values of 
dotlidStpPriority and dotldStpPortPriority have been 
clarified for bridges supporting IEEE 802.1t or 
IEEE 802.1w. 


The interpretation of dotldStpTimeSinceTopologyChange 
has been clarified for bridges supporting the Rapid 
Spanning Tree Protocol (RSTP)." 


REVISION "1993073100002" 
DESCRIPTION 
"Second revision, published as part of RFC 1493." 
REVISION "1991123100002" 
DESCRIPTION 


"Initial revision, published as part of RFC 1286." 
::= { mib-2 17 } 


BridgeId ::= TEXTUAL-CONVENTION 
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STATUS current 

DESCRIPTION 
"The Bridge-Identifier, as used in the Spanning Tree 
Protocol, to uniquely identify a bridge. Its first two 
octets (in network byte order) contain a priority value, 
and its last 6 octets contain the MAC address used to 
refer to a bridge in a unique fashion (typically, the 
numerically smallest MAC address of all ports on the 
bridge) ." 

SYNTAX OCTET STRING (SIZE (8)) 

Timeout ::= TEXTUAL-CONVENTION 

DISPLAY-HINT "q" 

STATUS current 

DESCRIPTION 
"A Spanning Tree Protocol (STP) timer in units of 1/100 
seconds. Several objects in this MIB module represent 


values of timers used by the Spanning Tree Protocol. 
In this MIB, these timers have values in units of 


hundredths of a second (i.e., 1/100 secs). 


These timers, when stored in a Spanning Tree Protocol’s 


BPDU, are in units of 1/256 seconds. Note, 


however, that 


802.1D-1998 specifies a settable granularity of no more 
than one second for these timers. To avoid ambiguity, 

a conversion algorithm is defined below for converting 
between the different units, which ensures a timer’s 


value is not distorted by multiple conversions. 


To convert a Timeout value into a value in units of 
1/256 seconds, the following algorithm should be used: 


b = floor( (n * 256) / 100) 


where: 
floor = quotient [ignore remainder] 
n is the value in 1/100 second units 
b is the value in 1/256 second units 


To convert the value from 1/256 second units back to 
1/100 seconds, the following algorithm should be used: 


n = ceiling( (b * 100) / 256) 


where: 
ceiling = quotient [if remainder is 0], 


quotient + 1 [if remainder is nonzero] 


n is the value in 1/100 second units 
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b is the value in 1/256 second units 


Note: it is important that the arithmetic operations are 
done in the order specified (i.e., multiply first, 
divide second) ." 

SYNTAX Integer32 


dotlidNotifications OBJECT IDENTIFIER ::= { dotldBridge 0 } 
dotlidBase OBJECT IDENTIFIER ::= { dotldBridge 1 } 
dotldstp OBJECT IDENTIFIER ::= { dotldBridge 2 } 
dotidSr OBJECT IDENTIFIER ::= { dotldBridge 3 } 


-- documented in RFC 1525 


dotldTp OBJECT IDENTIFIER ::= { dotldBridge 4 } 
dotidStatic OBJECT IDENTIFIER ::= { dotldBridge 5 } 


-—- Subtrees used by Bridge MIB Extensions: 

== pBridgeMIB MODULE-IDENTITY ::= { dotldBridge 6 } 

= qBridgeMIB MODULE-IDENTITY ::= { dotldBridge 7 } 

-—- Note that the practice of registering related MIB modules 
-—- below dotidBridge has been discouraged since there is no 

-—- robust mechanism to track such registrations. 


dotidConformance OBJECT IDENTIFIER ::= { dotldBridge 8 } 


-- Implementation of the dotldBase subtree is mandatory for all 
-—- bridges. 


dotidBaseBridgeAddress OBJECT-TYPE 


SYNTAX MacAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The MAC address used by this bridge when it must be 
referred to in a unique fashion. It is recommended 
that this be the numerically smallest MAC address of 
all ports that belong to this bridge. However, it is only 
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required to be unique. When concatenated with 
dotidStpPriority, a unique BridgeIdentifier is formed, 
which is used in the Spanning Tree Protocol." 
REFERENCE 
"IEEE 802.1D-1998: clauses 14.4.1.1.3 and 7.12.5" 
::= { dotldBase 1 } 


dotidBaseNumPorts OBJECT-TYPE 


SYNTAX Integer32 

UNITS "ports" 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The number of ports controlled by this bridging 
entity." 

REFERENCE 


"IEEE 802.1D-1998: clause 14.4.1.1.3" 
::= { dotldBase 2 } 


dotldBaseType OBJECT-TYPE 
SYNTAX INTEGER { 
unknown (1), 
transparent-—only (2), 
sourceroute-only (3), 
srt (4) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"Indicates what type of bridging this bridge can 
perform. If a bridge is actually performing a 
certain type of bridging, this will be indicated by 
entries in the port table for the given type." 
::= { dotldBase 3 } 


dotidBasePortTable OBJECT-TYPE 


SYNTAX SEQUENCE OF DotlidBasePortEntry 

MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 
"A table that contains generic information about every 
port that is associated with this bridge. Transparent, 


source-route, and srt ports are included." 
::= { dotldBase 4 } 
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dotidBasePortEntry OBJECT-TYPE 


SYNTAX DotldBasePortEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 
"A list of information for each port of the bridge." 
REFERENCE 


"TEEE 802.1D-1998: clause 14.4.2, 14.6.1" 
INDEX { dotldBasePort } 
::= { dotldBasePortTable 1 } 


DotlidBasePortEntry ::= 
SEQUENCE { 
dotldBasePort 
Integer32, 
dotldBasePortIfiIndex 
InterfaceIndex, 
dotlidBasePortCircuit 
OBJECT IDENTIFIER, 
dotlidBasePortDelayExceededDiscards 
Counter32, 
dotildBasePortMtuExceededDiscards 
Counter32 


} 


dotidBasePort OBJECT-TYPE 


SYNTAX Integer32 (1..65535) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"The port number of the port for which this entry 
contains bridge management information." 
::= { dotldBasePortEntry 1 } 


dotidBasePortIfIndex OBJECT-TYPE 


SYNTAX InterfaceIndex 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The value of the instance of the ifIndex object, 
defined in IF-MIB, for the interface corresponding 
to this port." 

:= { dotldBasePortEntry 2 } 


dotidBasePortCircuit OBJECT-TYPE 
SYNTAX OBJECT IDENTIFIER 
MAX-ACCESS read-only 
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STATUS current 

DESCRIPTION 
"For a port that (potentially) has the same value of 
dotidBasePortIfIndex as another port on the same bridge. 
This object contains the name of an object instance 
unique to this port. For example, in the case where 
multiple ports correspond one-to-one with multiple X.25 
virtual circuits, this value might identify an (e.g., 
the first) object instance associated with the X.25 
virtual circuit corresponding to this port. 


For a port which has a unique value of 
dotidBasePortIfIndex, this object can have the value 
RO E O ES 

:= { dotldBasePortEntry 3 } 


dotidBasePortDelayExceededDiscards OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"Ihe number of frames discarded by this port due 
to excessive transit delay through the bridge. It 
is incremented by both transparent and source 
route bridges." 

REFERENCE 
"IEEE 802.1D-1998: clause 14.6.1.1.3" 

::= { dotldBasePortEntry 4 } 


dotldBasePortMtuExceededDiscards OBJECT-TYPE 

SYNTAX Counter32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The number of frames discarded by this port due 
to an excessive size. It is incremented by both 
transparent and source route bridges." 

REFERENCE 
"IEEE 802.1D-1998: clause 14.6.1.1.3" 

::= { dotlidBasePortEntry 5 } 


—- Implementation of the dotldStp subtree is optional. It is 


—- implemented by those bridges that support the Spanning Tree 
-- Protocol. 
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dotldStpProtocolSpecification OBJECT-TYPE 
SYNTAX INTEGER { 
unknown (1), 
decLb100(2), 
ieee8021d (3) 
} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"An indication of what version of the Spanning Tree 
Protocol is being run. The value ’decLb100(2)’ 
indicates the DEC LANbridge 100 Spanning Tree protocol. 
IEEE 802.1D implementations will return ’ieee8021d(3)’. 
If future versions of the IEEE Spanning Tree Protocol 
that are incompatible with the current version 
are released a new value will be defined." 
::= { dotldStp 1 } 


dotlidStpPriority OBJECT-TYPE 

SYNTAX Integer32 (0..65535) 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 
"The value of the write-able portion of the Bridge ID 
(i.e., the first two octets of the (8 octet long) Bridge 
ID). The other (last) 6 octets of the Bridge ID are 
given by the value of dotldBaseBridgeAddress. 
On bridges supporting IEEE 802.1t or IEEE 802.1w, 
permissible values are 0-61440, in steps of 4096." 

REFERENCE 
"IEEE 802.1D-1998 clause 8.10.2, Table 8-4, 
IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3." 

::= { dotldStp 2 } 


dotlidStpTimeSinceTopologyChange OBJECT-TYPE 


SYNTAX TimeTicks 

UNITS "centi-seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The time (in hundredths of a second) since the 

last time a topology change was detected by the 

bridge entity. 

For RSTP, this reports the time since the tcWhile 

timer for any port on this Bridge was nonzero." 
REFERENCE 

"TEEE 802.1D-1998 clause 14.8.1.1., 

IEEE 802.1w clause 14.8.1.1." 
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::= { dotldStp 3 } 


dotldStpTopChanges OBJECT-TYPE 


SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The total number of topology changes detected by 
this bridge since the management entity was last 
reset or initialized." 

REFERENCE 
"IEEE 802.1D-1998 clause 14.8.1.1." 

::= { dotldStp 4 } 


dotlidStpDesignatedRoot OBJECT-TYPE 


SYNTAX BridgelId 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The bridge identifier of the root of the spanning 
tree, as determined by the Spanning Tree Protocol, 
as executed by this node. This value is used as 
the Root Identifier parameter in all Configuration 
Bridge PDUs originated by this node." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.1" 

::= { dotldStp 5 } 


dotldStpRootCost OBJECT-TYPE 


SYNTAX Integer32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The cost of the path to the root as seen from 
this bridge." 

REFERENCE 
"TEEE 802.1D-1998: clause 8.5.3.2" 

::= { dotldStp 6 } 


dotldStpRootPort OBJECT-TYPE 


SYNTAX Integer32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The port number of the port that offers the lowest 

cost path from this bridge to the root bridge." 
REFERENCE 

"IEEE 802.1D-1998: clause 8.5.3.3" 


Norseth & Bell, Eds. Standards Track [Page 16] 


RFC 4188 Bridge MIB September 2005 


::= { dotldStp 7 } 


dotldStpMaxAge OBJECT-TYPE 


SYNTAX Timeout 

UNITS "centi-seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The maximum age of Spanning Tree Protocol information 
learned from the network on any port before it is 
discarded, in units of hundredths of a second. This is 
the actual value that this bridge is currently using." 
REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.4" 
:= { dotldStp 8 } 


dotlidStpHelloTime OBJECT-TYPE 


SYNTAX Timeout 

UNITS "centi-seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The amount of time between the transmission of 
Configuration bridge PDUs by this node on any port when 
it is the root of the spanning tree, or trying to become 
so, in units of hundredths of a second. This is the 
actual value that this bridge is currently using." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.5" 

:= { dotldStp 9 } 


dotldStpHoldTime OBJECT-TYPE 


SYNTAX Integer32 

UNITS "centi-seconds" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"This time value determines the interval length 
during which no more than two Configuration bridge 
PDUs shall be transmitted by this node, in units 
of hundredths of a second." 
REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.14" 
:= { dotldStp 10 } 


dotidStpForwardDelay OBJECT-TYPE 


SYNTAX Timeout 
UNITS "centi-seconds" 
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MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"This time value, measured in units of hundredths of a 
second, controls how fast a port changes its spanning 
state when moving towards the Forwarding state. The 
value determines how long the port stays in each of the 
Listening and Learning states, which precede the 
Forwarding state. This value is also used when a 
topology change has been detected and is underway, to 
age all dynamic entries in the Forwarding Database. 
[Note that this value is the one that this bridge is 
currently using, in contrast to 
dotldStpBridgeForwardDelay, which is the value that this 
bridge and all others would start using if/when this 
bridge were to become the root.]" 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.6" 

::= { dotldStp 11 } 


dotlidStpBridgeMaxAge OBJECT-TYPE 


SYNTAX Timeout (600..4000) 
UNITS "centi-seconds" 
MAX-ACCESS read-write 

STATUS current 
DESCRIPTION 


"The value that all bridges use for MaxAge when this 
bridge is acting as the root. Note that 802.1D-1998 
specifies that the range for this parameter is related 
to the value of dotlidStpBridgeHelloTime. The 
granularity of this timer is specified by 802.1D-1998 to 
be 1 second. An agent may return a badValue error if a 
set is attempted to a value that is not a whole number 
of seconds." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.8" 

:= { dotldStp 12 } 


dotlidStpBridgeHelloTime OBJECT-TYPE 


SYNTAX Timeout (100..1000) 

UNITS "centi-seconds" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 
"The value that all bridges use for HelloTime when this 
bridge is acting as the root. The granularity of this 


timer is specified by 802.1D-1998 to be 1 second. An 
agent may return a badValue error if a set is attempted 
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to a value that is not a whole number of seconds." 
REFERENCE 

"IEEE 802.1D-1998: clause 8.5.3.9" 
::= { dotldStp 13 } 


dotldStpBridgeForwardDelay OBJECT-TYPE 


SYNTAX Timeout (400..3000) 
UNITS "centi-seconds" 
MAX-ACCESS read-write 

STATUS current 
DESCRIPTION 


"The value that all bridges use for ForwardDelay when 
this bridge is acting as the root. Note that 
802.1D-1998 specifies that the range for this parameter 
is related to the value of dotldStpBridgeMaxAge. The 
granularity of this timer is specified by 802.1D-1998 to 
be 1 second. An agent may return a badValue error if a 
set is attempted to a value that is not a whole number 
of seconds." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.3.10" 

:= { dotldStp 14 } 


dotlidStpPortTable OBJECT-TYPE 


SYNTAX SEQUENCE OF DotildStpPortEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"A table that contains port-specific information 
for the Spanning Tree Protocol." 
::= { dotldStp 15 } 


dotidStpPortEntry OBJECT-TYPE 


SYNTAX Dot1ldStpPortEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"A list of information maintained by every port about 
the Spanning Tree Protocol state for that port." 
INDEX { dotlidStpPort } 
:= { dotldStpPortTable 1 } 


DotldStpPortEntry ::= 
SEQUENCE { 
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dotlidStpPort 
Integer32, 
dotldStpPortPriority 
Integer32, 
dotldStpPortState 
INTEGER, 
dotldStpPortEnable 
INTEGER, 
dotldStpPortPathCost 
Integer32, 
dotldStpPortDesignatedRoot 
Bridgeld, 
dotldStpPortDesignatedCost 
Integer32, 
dotldStpPortDesignatedBridge 
Bridgeld, 
dotlidStpPortDesignatedPort 
OCTET STRING, 
dotldStpPortForwardTransitions 
Counter32, 
dotldStpPortPathCost32 
Integer32 


} 


dotlidStpPort OBJECT-TYPE 


SYNTAX Integer32 (1..65535) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"The port number of the port for which this entry 
contains Spanning Tree Protocol management information." 
REFERENCE 
"IEEE 802.1D-1998: clause 14.8.2.1.2" 
::= { dotldStpPortEntry 1 } 


dotlidStpPortPriority OBJECT-TYPE 


SYNTAX Integer32 (0..255) 
MAX-ACCESS read-write 

STATUS current 
DESCRIPTION 


"The value of the priority field that is contained in 

the first (in network byte order) octet of the (2 octet 

long) Port ID. The other octet of the Port ID is given 

by the value of dotldStpPort. 

On bridges supporting IEEE 802.1t or IEEE 802.1w, 

permissible values are 0-240, in steps of 16." 
REFERENCE 

"IEEE 802.1D-1998 clause 8.10.2, Table 8-4, 
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IEEE 802.1t clause 8.10.2, Table 8-4, clause 14.3." 
::= { dotldStpPortEntry 2 } 


dotldStpPortState OBJECT-TYPE 
SYNTAX INTEGER { 

disabled(1 

blocking (2 

listening ( 

learning (4), 

forwarding(5), 
broken (6) 


r 


) 
y 
3), 
) 


} 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The port’s current state, as defined by application of 
the Spanning Tree Protocol. This state controls what 
action a port takes on reception of a frame. If the 
bridge has detected a port that is malfunctioning, it 
will place that port into the broken(6) state. For 
ports that are disabled (see dotlidStpPortEnable), this 
object will have a value of disabled(1)." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.5.2" 

::= { dotldStpPortEntry 3 } 


dotldStpPortEnable OBJECT-TYPE 
SYNTAX INTEGER { 
enabled(1), 
disabled (2) 
} 
MAX-ACCESS read-write 
STATUS current 
DESCRIPTION 
"The enabled/disabled status of the port." 
REFERENCE 
"TEEE 802.1D-1998: clause 8.5.5.2" 
::= { dotldStpPortEntry 4 } 


dotldStpPortPathCost OBJECT-TYPE 


SYNTAX Integer32 (1..65535) 
MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"The contribution of this port to the path cost of 
paths towards the spanning tree root which include 
this port. 802.1D-1998 recommends that the default 
value of this parameter be in inverse proportion to 
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the speed of the attached LAN. 


New implementations should support dotldStpPortPathCost32. 
If the port path costs exceeds the maximum value of this 
object then this object should report the maximum value, 
namely 65535. Applications should try to read the 
dotldStpPortPathCost32 object if this object reports 
the maximum value." 

REFERENCE "IEEE 802.1D-1998: clause 8.5.5.3" 
::= { dotldStpPortEntry 5 } 


dotldStpPortDesignatedRoot OBJECT-TYPE 


SYNTAX Bridgeld 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The unique Bridge Identifier of the Bridge 
recorded as the Root in the Configuration BPDUs 
transmitted by the Designated Bridge for the 
segment to which the port is attached." 
REFERENCE 
"IEEE 802.1D-1998: clause 8.5.5.4" 
::= { dotldStpPortEntry 6 } 


dotldStpPortDesignatedCost OBJECT-TYPE 

SYNTAX Integer32 

MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The path cost of the Designated Port of the segment 
connected to this port. This value is compared to the 
Root Path Cost field in received bridge PDUs." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.5.5" 

::= { dotldStpPortEntry 7 } 


dotldStpPortDesignatedBridge OBJECT-TYPE 


SYNTAX Bridgeld 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The Bridge Identifier of the bridge that this 
port considers to be the Designated Bridge for 
this port’s segment." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.5.6" 

::= { dotldStpPortEntry 8 } 


Norseth & Bell, Eds. Standards Track [Page 22] 


RFC 4188 Bridge MIB September 2005 


dotldStpPortDesignatedPort OBJECT-TYPE 


SYNTAX OCTET STRING (SIZE (2)) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"The Port Identifier of the port on the Designated 
Bridge for this port’s segment." 

REFERENCE 
"IEEE 802.1D-1998: clause 8.5.5.7" 

::= { dotldStpPortEntry 9 } 


dotldStpPortForwardTransitions OBJECT-TYPE 


SYNTAX Counter32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The number of times this port has transitioned 
from the Learning state to the Forwarding state." 
::= { dotldStpPortEntry 10 } 


dotidStpPortPathCost32 OBJECT-TYPE 


SYNTAX Integer32 (1..200000000) 
MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"The contribution of this port to the path cost of 
paths towards the spanning tree root which include 
this port. 802.1D-1998 recommends that the default 
value of this parameter be in inverse proportion to 
the speed of the attached LAN. 


This object replaces dotldStpPortPathCost to support 
IEEE 802.1t." 

REFERENCE 
"IEEE 802.1t clause 8.10.2, Table 8-5." 

::= { dotldStpPortEntry 11 } 


—- Implementation of the dotldTp subtree is optional. It is 
—-- implemented by those bridges that support the transparent 
-—- bridging mode. A transparent or SRT bridge will implement 
-- this subtree. 


dotldTpLearnedEntryDiscards OBJECT-TYPE 
SYNTAX Counter32 
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MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 
"The total number of Forwarding Database entries that 
have been or would have been learned, but have been 
discarded due to a lack of storage space in the 
Forwarding Database. If this counter is increasing, it 
indicates that the Forwarding Database is regularly 
becoming full (a condition that has unpleasant 
performance effects on the subnetwork). If this counter 
has a significant value but is not presently increasing, 
it indicates that the problem has been occurring but is 
not persistent." 

REFERENCE 
"IEEE 802.1D-1998: clause 14.7.1.1.3" 

::= { dotldTp 1 } 


dotldTpAgingTime OBJECT-TYPE 


SYNTAX Integer32 (10..1000000) 
UNITS "seconds" 

MAX-ACCESS read-write 

STATUS current 

DESCRIPTION 


"The timeout period in seconds for aging out 
dynamically-learned forwarding information. 
802.1D-1998 recommends a default of 300 seconds." 
REFERENCE 
"IEEE 802.1D-1998: clause 14.7.1.1.3" 
:= { dotldTp 2 } 


dotldTpFdbTable OBJECT-TYPE 


SYNTAX SEQUENCE OF DotldTpFdbEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"A table that contains information about unicast 

entries for which the bridge has forwarding and/or 

filtering information. This information is used 

by the transparent bridging function in 

determining how to propagate a received frame." 
::= { dotldTp 3 } 


dotlidTpFdbEntry OBJECT-TYPE 
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SYNTAX DotldTpFdbEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"Information about a specific unicast MAC address 
for which the bridge has some forwarding and/or 
filtering information." 

INDEX { dotlidTpFdbAddress } 

::= { dotldTpFdbTable 1 } 


DotldTpFdbEntry ::= 
SEQUENCE { 
dotldTpFdbAddress 
MacAddress, 
dotldTpFdbPort 
Integer32, 
dotldTpFdbStatus 
INTEGER 
} 


dotldTpFdbAddress OBJECT-TYPE 


SYNTAX MacAddress 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"A unicast MAC address for which the bridge has 
forwarding and/or filtering information." 
REFERENCE 
"IEEE 802.1D-1998: clause 7.9.1, 7.9.2" 
:= { dotldTpFdbEntry 1 } 


dotldTpFdbPort OBJECT-TYPE 


SYNTAX Integer32 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"Either the value ’0’, or the port number of the port on 
which a frame having a source address equal to the value 
of the corresponding instance of dotldTpFdbAddress has 
been seen. A value of ’0’ indicates that the port 
number has not been learned, but that the bridge does 
have some forwarding/filtering information about this 
address (e.g., in the dotldStaticTable). Implementors 
are encouraged to assign the port value to this object 
whenever it is learned, even for addresses for which the 
corresponding value of dotldTpFdbStatus is not 
learned (3)." 

::= { dotldTpFdbEntry 2 } 
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dotldTpFdbStatus OBJECT-TYPE 
SYNTAX INTEGER { 
other (1) 
invalid ( 
learned ( 
self (4), 
mgmt (5) 


2) 
3 


y 


} 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 
"The status of this entry. The meanings of the 
values are: 
other(1) - none of the following. This would 
include the case where some other MIB object 
(not the corresponding instance of 
dotldTpFdbPort, nor an entry in the 
dotlidStaticTable) is being used to determine if 
and how frames addressed to the value of the 
corresponding instance of dotldTpFdbAddress are 
being forwarded. 
invalid(2) - this entry is no longer valid (e.g., 
it was learned but has since aged out), but has 
not yet been flushed from the table. 
learned(3) - the value of the corresponding instance 
of dotldTpFdbPort was learned, and is being 
used. 
self(4) - the value of the corresponding instance of 
dotldTpFdbAddress represents one of the bridge’s 
addresses. The corresponding instance of 
dotldTpFdbPort indicates which of the bridge’s 
ports has this address. 
mgmt (5) - the value of the corresponding instance of 
dotldTpFdbAddress is also the value of an 
existing instance of dotldStaticAddress." 
::= { dotldTpFdbEntry 3 } 


dotldTpPortTable OBJECT-TYPE 


SYNTAX SEQUENCE OF DotildTpPortEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"A table that contains information about every port that 
is associated with this transparent bridge." 
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::= { dotldTp 4 } 


dotlidTpPortEntry OBJECT-TYPE 


SYNTAX DotldTpPortEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


September 2005 


"A list of information for each port of a transparent 


bridge." 
INDEX { dotldTpPort } 
::= { dotldTpPortTable 1 } 


DotldTpPortEntry ::= 
SEQUENCE { 
dotldTpPort 
Integer32, 
dotldTpPortMaxInfo 
Integer32, 
dotldTpPortInFrames 
Counter32, 
dotldTpPortOutFrames 
Counter32, 
dotldTpPortInDiscards 
Counter32 
} 


dotldTpPort OBJECT-TYPE 


SYNTAX Integer32 (1..65535) 
MAX-ACCESS read-only 

STATUS current 

DESCRIPTION 


"The port number of the port for which this entry 
contains Transparent bridging management information." 


::= { dotldTpPortEntry 1 } 


-- It would be nice if we could use ifMtu as the size of the 

—-- largest INFO field, but we can’t because ifMtu is defined 

-- to be the size that the (inter-)network layer can use, which 
-- can differ from the MAC layer (especially if several layers 


-—- of encapsulation are used). 


dotlidTpPortMaxInfo OBJECT-TYPE 


SYNTAX Integer32 
UNITS "bytes" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The maximum size of the INFO (non-MAC) 
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this port will receive or transmit." 
::= { dotldTpPortEntry 2 } 


dotldTpPortInFrames OBJECT-TYPE 


SYNTAX Counter32 
UNITS "frames" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The number of frames that have been received by this 
port from its segment. Note that a frame received on the 
interface corresponding to this port is only counted by 
this object if and only if it is for a protocol being 
processed by the local bridging function, including 
bridge management frames." 

REFERENCE 
"TEEE 802.1D-1998: clause 14.6.1.1.3" 

::= { dotldTpPortEntry 3 } 


dotldTpPortOutFrames OBJECT-TYPE 


SYNTAX Counter32 
UNITS "frames" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"The number of frames that have been transmitted by this 
port to its segment. Note that a frame transmitted on 
the interface corresponding to this port is only counted 
by this object if and only if it is for a protocol being 
processed by the local bridging function, including 
bridge management frames." 

REFERENCE 
"TEEE 802.1D-1998: clause 14.6.1.1.3" 

::= { dotldTpPortEntry 4 } 


dotlidTpPortInDiscards OBJECT-TYPE 


SYNTAX Counter32 
UNITS "frames" 
MAX-ACCESS read-only 
STATUS current 
DESCRIPTION 


"Count of received valid frames that were discarded 
(i.e., filtered) by the Forwarding Process." 
REFERENCE 
"IEEE 802.1D-1998: clause 14.6.1.1.3" 
::= { dotldTpPortEntry 5 } 
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-—- The Static (Destination-Address Filtering) Database 


dotidStaticTable OBJECT-TYPE 


SYNTAX SEQUENCE OF DotidStaticEntry 
MAX-ACCESS not-accessible 

STATUS current 

DESCRIPTION 


"A table containing filtering information configured 
into the bridge by (local or network) management 
specifying the set of ports to which frames received 
from specific ports and containing specific destination 
addresses are allowed to be forwarded. The value of 
zero in this table, as the port number from which frames 
with a specific destination address are received, is 
used to specify all ports for which there is no specific 
entry in this table for that particular destination 


address. Entries are valid for unicast and for 
group/broadcast addresses." 
REFERENCE 


"IEEE 802.1D-1998: clause 14.7.2" 
::= { dotldStatic 1 } 


dotidStaticEntry OBJECT-TYPE 


SYNTAX DotldStaticEntry 
MAX-ACCESS not-accessible 
STATUS current 
DESCRIPTION 


"Filtering information configured into the bridge by 
(local or network) management specifying the set of 
ports to which frames received from a specific port and 
containing a specific destination address are allowed to 
be forwarded." 

REFERENCE 
"IEEE 802.1D-1998: clause 14.7.2" 

INDEX { dotidStaticAddress, dotidStaticReceivePort } 

::= { dotldStaticTable 1 } 


DotldStaticEntry ::= 
SEQUENCE { 
dotidStaticAddress MacAddress, 
dotidStaticReceivePort Integer32, 
dotidStaticAllowedToGoTo OCTET STRING, 
dotidStaticStatus INTEGER 
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dotlidStaticAddress OBJECT-TYPE 

SYNTAX MacAddress 

MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 
"The destination MAC address in a frame to which this 
entry’s filtering information applies. This object can 
take the value of a unicast address, a group address, or 
the broadcast address." 

REFERENCE 
"IEEE 802.1D-1998: clause 7.9.1, 7.9.2" 

::= { dotldStaticEntry 1 } 


dotlidStaticReceivePort OBJECT-TYPE 


SYNTAX Integer32 (0..65535) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"Either the value ’0’, or the port number of the port 

from which a frame must be received in order for this 

entry’s filtering information to apply. A value of zero 

indicates that this entry applies on all ports of the 

bridge for which there is no other applicable entry." 
::= { dotldStaticEntry 2 } 


dotlidStaticAllowedToGoTo OBJECT-TYPE 


SYNTAX OCTET STRING (SIZE (0..512)) 
MAX-ACCESS read-create 

STATUS current 

DESCRIPTION 


"The set of ports to which frames received from a 
specific port and destined for a specific MAC address, 
are allowed to be forwarded. Each octet within the 
value of this object specifies a set of eight ports, 
with the first octet specifying ports 1 through 8, the 
second octet specifying ports 9 through 16, etc. Within 
each octet, the most significant bit represents the 
lowest numbered port, and the least significant bit 
represents the highest numbered port. Thus, each port 
of the bridge is represented by a single bit within the 
value of this object. If that bit has a value of ’1’, 
then that port is included in the set of ports; the port 


is not included if its bit has a value of ’0’. (Note 
that the setting of the bit corresponding to the port 
from which a frame is received is irrelevant.) The 


default value of this object is a string of ones of 
appropriate length. 
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The value of this object may exceed the required minimum 

maximum message size of some SNMP transport (484 bytes, 

in the case of SNMP over UDP, see RFC 3417, section 3.2). 

SNMP engines on bridges supporting a large number of 

ports must support appropriate maximum message sizes." 
::= { dotldStaticEntry 3 } 


dotidStaticStatus OBJECT-TYPE 
SYNTAX INTEGER { 
other (1), 
invalid(2), 
permanent (3), 
deleteOnReset (4), 
deleteOnTimeout (5) 
} 
MAX-ACCESS read-create 
STATUS current 
DESCRIPTION 
"This object indicates the status of this entry. 
The default value is permanent (3). 
other(1) - this entry is currently in use but the 
conditions under which it will remain so are 
different from each of the following values. 


invalid(2) - writing this value to the object 
removes the corresponding entry. 

permanent (3) - this entry is currently in use and 
will remain so after the next reset of the 
bridge. 

deleteOnReset (4) - this entry is currently in use 
and will remain so until the next reset of the 
bridge. 

deleteOnTimeout (5) - this entry is currently in use 


and will remain so until it is aged out." 
::= { dotldStaticEntry 4 } 


newRoot NOTIFICATION-TYPE 


-- OBJECTS { } 
STATUS current 
DESCRIPTION 


"The newRoot trap indicates that the sending agent has 
become the new root of the Spanning Tree; the trap is 
sent by a bridge soon after its election as the new 
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root, e.g., upon expiration of the Topology Change Timer, 
immediately subsequent to its election. Implementation 
of this trap is optional." 

::= { dotldNotifications 1 } 


topologyChange NOTIFICATION-TYPE 


-- OBJECTS { } 
STATUS current 
DESCRIPTION 


"A topologyChange trap is sent by a bridge when any of 
its configured ports transitions from the Learning state 
to the Forwarding state, or from the Forwarding state to 
the Blocking state. The trap is not sent if a newRoot 
trap is sent for the same transition. Implementation of 
this trap is optional." 

::= { dotldNotifications 2 } 


dotldGroups OBJECT IDENTIFIER ::= { dotldConformance 1 } 
dotidCompliances OBJECT IDENTIFIER ::= { dotldConformance 2 } 


dotidBaseBridgeGroup OBJECT-GROUP 
OBJECTS { 
dotlidBaseBridgeAddress, 
dotidBaseNumPorts, 
dotldBaseType 
} 
STATUS current 
DESCRIPTION 
"Bridge level information for this device." 
::= { dotldGroups 1 } 


dotldBasePortGroup OBJECT-GROUP 
OBJECTS { 
dotidBasePort, 
dotldBasePortIfIndex, 
dotlidBasePortCircuit, 
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dotlidBasePortDelayExceededDiscards, 
dot1ldBasePortMtuExceededDiscards 
} 
STATUS current 
DESCRIPTION 
"Information for each port on this device." 
:= { dotldGroups 2 } 


dotldStpBridgeGroup OBJECT-—GROUP 

OBJECTS { 
dotldStpProtocolSpecification, 
dotidStpPriority, 
dotldStpTimeSinceTopologyChange, 
dotldStpTopChanges, 
dotldStpDesignatedRoot, 
dotldStpRootCost, 
dotldStpRootPort, 
dotldsStpMaxAge, 
dotidStpHelloTime, 
dotldStpHoldTime, 
dotlidStpForwardDelay, 
dotldStpBridgeMaxAge, 
dotldStpBridgeHelloTime, 
dotldStpBridgeForwardDelay 

} 

STATUS current 

DESCRIPTION 
"Bridge level Spanning Tree data for this device." 

::= { dotldGroups 3 } 


dotldStpPortGroup OBJECT-GROUP 

OBJECTS { 
dotlidStpPort, 
dotldStpPortPriority, 
dotldStpPortState, 
dotlidStpPortEnable, 
dotldsStpPortPathCost, 
dotldStpPortDesignatedRoot, 
dotldStpPortDesignatedCost, 
dotldStpPortDesignatedBridge, 
dotlidStpPortDesignatedPort, 
dotldStpPortForwardTransitions 

} 

STATUS current 


Norseth & Bell, Eds. Standards Track [Page 33] 


RFC 4188 Bridge MIB September 2005 


DESCRIPTION 
"Spanning Tree data for each port on this device." 
::= { dotldGroups 4 } 


dotldStpPortGroup2 OBJECT-GROUP 

OBJECTS { 
dotidStpPort, 
dotldStpPortPriority, 
dotldStpPortState, 
dotldStpPortEnable, 
dotldStpPortDesignatedRoot, 
dotldStpPortDesignatedCost, 
dotldStpPortDesignatedBridge, 
dotlidStpPortDesignatedPort, 
dotldStpPortForwardTransitions, 
dotlidStpPortPathCost32 

} 

STATUS current 

DESCRIPTION 
"Spanning Tree data for each port on this device." 

::= { dotldGroups 5 } 


dotldStpPortGroup3 OBJECT-GROUP 

OBJECTS { 
dotldStpPortPathCost32 

} 

STATUS current 

DESCRIPTION 
"Spanning Tree data for devices supporting 32-bit 
path costs." 

::= { dotldGroups 6 } 


dotldTpBridgeGroup OBJECT-GROUP 

OBJECTS { 
dotlidTpLearnedEntryDiscards, 
dotldTpAgingTime 

} 

STATUS current 

DESCRIPTION 
"Bridge level Transparent Bridging data." 

:= { dotldGroups 7 } 


dotldTpFdbGroup OBJECT-GROUP 
OBJECTS { 
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dotldTpFdbAddress, 
dotldTpFdbPort, 
dotldTpFdbStatus 


STATUS current 
DESCRIPTION 

"Filtering Database information for the Bridge." 
::= { dotldGroups 8 } 


dotldTpGroup OBJECT-GROUP 

OBJECTS { 
dotldTpPort, 
dotldTpPortMaxiInfo, 
dotidTpPortiInFrames, 
dotldTpPortOutFrames, 
dotldTpPortInDiscards 

} 

STATUS current 

DESCRIPTION 
"Dynamic Filtering Database information for each port of 
the Bridge." 

::= { dotldGroups 9 } 


-—- The Static (Destination-Address Filtering) Database 


dotidStaticGroup OBJECT-GROUP 

OBJECTS { 
dotlidStaticAddress, 
dotldStaticReceivePort, 
dotidStaticAllowedToGoTo, 
dotidStaticStatus 

} 

STATUS current 

DESCRIPTION 
"Static Filtering Database information for each port of 
the Bridge." 

::= { dotldGroups 10 } 


dotlidNotificationGroup NOTIFICATION-GROUP 
NOTIFICATIONS { 
newRoot, 
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topologyChange 
} 
STATUS current 
DESCRIPTION 
"Group of objects describing notifications (traps)." 
::= { dotldGroups 11 } 


bridgeCompliance1l493 MODULE-COMPLIANCE 
STATUS current 
DESCRIPTION 
"The compliance statement for device support of bridging 
services, as per RFC1493." 


MODULE 
MANDATORY-GROUPS { 
dotlidBaseBridgeGroup, 
dot1ldBasePortGroup 
} 


GROUP dotldStpBridgeGroup 

DESCRIPTION 
"Implementation of this group is mandatory for bridges 
that support the Spanning Tree Protocol." 


GROUP dotldStpPortGroup 

DESCRIPTION 
"Implementation of this group is mandatory for bridges 
that support the Spanning Tree Protocol." 


GROUP dotldTpBridgeGroup 

DESCRIPTION 
"Implementation of this group is mandatory for bridges 
that support the transparent bridging mode. A 
transparent or SRT bridge will implement this group." 


GROUP dotldTpFdbGroup 

DESCRIPTION 
"Implementation of this group is mandatory for bridges 
that support the transparent bridging mode. A 
transparent or SRT bridge will implement this group." 


GROUP dotldTpGroup 


DESCRIPTION 
"Implementation of this group is mandatory for bridges 
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that support the transparent bridging mode. A 
transparent or SRT bridge will implement this group." 


GROUP dotidStaticGroup 
DESCRIPTION 
"Implementation of this group is optional." 


GROUP dotldNotificationGroup 
DESCRIPTION 

"Implementation of this group is optional." 
::= { dotldCompliances 1 } 


bridgeCompliance4188 MODULE-COMPLIANCE 


STATUS current 

DESCRIPTION 
"The compliance statement for device support of bridging 
services. This supports 32-bit Path Cost values and the 
more restricted bridge and port priorities, as per IEEE 
802.1t. 


Full support for the 802.1D management objects requires that 
the SNMPv2-MIB [RFC3418] objects sysDescr, and sysUpTime, as 
well as the IF-MIB [RFC2863] objects ifIndex, ifType, 
ifDescr, ifPhysAddress, and ifLastChange are implemented." 


MODULE 
MANDATORY-GROUPS { 
dotidBaseBridgeGroup, 
dot1ldBasePortGroup 


} 


GROUP dotldStpBridgeGroup 

DESCRIPTION 
"Implementation of this group is mandatory for 
bridges that support the Spanning Tree Protocol." 


OBJECT dotlidStpPriority 
SYNTAX Integer32 (0|4096|8192|12288|16384|20480|24576 
|28672|32768|36864|40960|45056|49152 
|53248|57344| 61440) 
DESCRIPTION 
"The possible values defined by IEEE 802.1t." 


GROUP dotldStpPortGroup2 

DESCRIPTION 
"Implementation of this group is mandatory for 
bridges that support the Spanning Tree Protocol." 
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GROUP dotldStpPortGroup3 

DESCRIPTION 
"Implementation of this group is mandatory for bridges 
that support the Spanning Tree Protocol and 32-bit path 
costs. In particular, this includes devices supporting 
IEEE 802.1t and IEEE 802.1w." 


OBJECT dotlidStpPortPriority 
SYNTAX Integer32 (0|16|32/48|64|80|96|112|128 
|144|160|176|192|208]224| 240) 
DESCRIPTION 
"The possible values defined by IEEE 802.1t." 


GROUP dotldTpBridgeGroup 

DESCRIPTION 
"Implementation of this group is mandatory for 
bridges that support the transparent bridging 
mode. A transparent or SRT bridge will implement 
this group." 


GROUP dotldTpFdbGroup 

DESCRIPTION 
"Implementation of this group is mandatory for 
bridges that support the transparent bridging 
mode. A transparent or SRT bridge will implement 
this group." 


GROUP dotldTpGroup 

DESCRIPTION 
"Implementation of this group is mandatory for 
bridges that support the transparent bridging 
mode. A transparent or SRT bridge will implement 
this group." 


GROUP dotlidStaticGroup 
DESCRIPTION 
"Implementation of this group is optional." 
GROUP dotldNotificationGroup 
DESCRIPTION 
"Implementation of this group is optional." 


::= { dotldCompliances 2 } 


END 
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3% 


IANA Considerations 


The MIB module in this document uses the following IANA-assigned 
OBJECT IDENTIFIER values that are recorded in the SMI Numbers 
registry: 


Descriptor OBJECT IDENTIFIER value 


dotidBridge { mib-2 17 } 


Security Considerations 


There are a number of management objects defined in this MIB module 
that have a MAX-ACCESS clause of read-write and/or read-create. Such 
objects may be considered sensitive or vulnerable in some network 
environments. The support for SET operations in a non-secure 
environment without proper protection can have a negative effect on 
network operations. 


Some of the readable objects in this MIB module (i.e., objects with a 
MAX-ACCESS other than not-accessible) may be considered sensitive or 
vulnerable in some network environments. It is thus important to 
control even GET and/or NOTIFY access to these objects and possibly 
to even encrypt the values of these objects when sending them over 
the network via SNMP. 


These are the tables and objects and their sensitivity/vulnerability: 


o The writable objects dotlidStpPriority, dotldStpBridgeMaxAge, 
dotldStpBridgeHelloTime, dotldStpBridgeForwardDelay, 
dotldStpPortPriority, dotldStpPortEnable, dotldStpPortPathCost, 
and dotldStpPortPathCost32 influence the spanning tree protocol. 
Unauthorized write access to these objects can cause the spanning 
tree protocol to compute other default topologies or it can change 
the speed in which the spanning tree protocol reacts to failures. 


o The writable object dotldTpAgingTime controls how fast 
dynamically-learned forwarding information is aged out. Setting 
this object to a large value may simplify forwarding table 
overflow attacks. 


o The writable dotldStaticTable provides a filtering mechanism 
controlling to which ports frames originating from a specific 
source may be forwarded. Write access to this table can be used 
to turn provisioned filtering off or to add filters to prevent 
rightful use of the network. 
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o The readable objects defined in the BRIDGE-MIB module provide 
information about the topology of a bridged network and the 
attached active stations. The addresses listed in the 
dotldTpFdbTable usually reveal information about the manufacturer 
of the MAC hardware, which can be useful information for mounting 
other specific attacks. 


o The two notifications newRoot and topologyChange are emitted 
during spanning tree computation and may trigger management 
systems to inspect the status of bridges and to recompute internal 
topology information. Hence, forged notifications may cause 
management systems to perform unnecessary computations and to 
generate additional SNMP traffic directed to the bridges in a 
network. Therefore, forged notifications may be part of a denial 
of service attack. 


SNMP versions prior to SNMPv3 did not include adequate security. 

Even if the network itself is secure (for example by using IPSec), 
even then, there is no control as to who on the secure network is 
allowed to access and GET/SET (read/change/create/delete) the objects 
in this MIB module. 


It is RECOMMENDED that implementers consider the security features as 
provided by the SNMPv3 framework (see [RFC3410], section 8), 
including full support for the SNMPv3 cryptographic mechanisms (for 
authentication and privacy). 


Further, deployment of SNMP versions prior to SNMPv3 is NOT 
RECOMMENDED. Instead, it is RECOMMENDED to deploy SNMPv3 and to 
enable cryptographic security. It is then a customer/operator 
responsibility to ensure that the SNMP entity giving access to an 
instance of this MIB module is properly configured to give access to 
the objects only to those principals (users) that have legitimate 
rights to indeed GET or SET (change/create/delete) them. 
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9. Changes from RFC 1493 
The following changes have been made from RFC 1493. 


1. Translated the MIB definitions to use SMIv2. This includes the 
introduction of conformance statements. ASN.1 type definitions 
have been converted into textual-conventions and several UNITS 
clauses were added. 


2. The object dotldStpPortPathCost32 was added to support IEEE 
802.1t. 


3. Permissible values for dotldStpPriority and dotldStpPortPriority 
have been clarified for bridges supporting IEEE 802.1t or IEEE 
802.1w. 

4. Interpretation of dotldStpTimeSinceTopologyChange has been 
clarified for bridges supporting the rapid spanning tree protocol 
(RSTP). 

5. Updated the introductory boilerplate text, the security 
considerations section, and the references to comply with the 
current IETF standards and guidelines. 

6. Updated references to point to newer IEEE 802.1d documents. 

7. Additions and clarifications in various description clauses. 
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